Shared Storage

[etrouton]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Shared Storage
• Specification or proposal URL: https://github.com/WICG/shared-storage
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional): @asutherland

Other information

• Chrome status page: https://chromestatus.com/feature/6256348582903808

Note that Chrome is implementing (with spec following shortly after) but we're quite open to evolving the API over time and are appreciative of your feedback. Thank you!

[etrouton]

Hi Mozilla team - it seems we might be a bit early in the process to formally request feedback. I will go ahead and close the ticket for now, but we would love to discuss if you have any thoughts or feedback as we incubate this proposal. Thank you!

[etrouton]

Hi Mozilla team, we have been incubating shared storage in WICG (moved to https://github.com/WICG/shared-storage) and believe we are now ready for your review and feedback, so I'm reopening the request. We continue to be open to changes and would love to hear your thoughts. Thanks!

[martinthomson]

We have concluded that Mozilla takes a negative position on this proposal.

From a technical perspective, this is not a storage proposal, but a new form of isolated execution environment. This is unlike workers or other execution environments that exist on the web in that it operates on data that the entity providing code has no incentive to keep private; indeed, the opposite is true: they have strong incentive to exfiltrate what they gain access to.

We have no evidence to suggest that this might be a viable design. We’ve asked a number of researchers about whether this sort of isolation is technically possible, but are pessimistic about the answer to that question given our own experience and knowledge.

We also have reservations about the size and complexity of the design, plus the privacy characteristics of the URL selection design as they relate to k-anonymity and budgeting. We can talk more about some of those, but we’d prefer to see whether the use cases justify the effort.

Though this is presented as a general purpose API, the need to severely restrict the flow of information that leaves the isolated realm means that this ends up addressing very specific applications. A few applications were identified for this:

• Consistent A/B trials across different sites. We don’t believe that the value of this feature would come anywhere close to justifying the complexity of this design.

• Various ad measurement pieces. We do think that providing measurement for advertising is a worthwhile and achievable goal. This is a clever application of some generic design components, but we believe that there could be superior approaches for the primary use cases.

  • For reach and frequency, we believe that a heuristic-based approach, such as one based on virtual IDs - or similar, simpler models - is more likely to provide useful results. These are delay sensitive applications and we don’t believe that the gain in utility resulting from a delayed measurement warrants the risk of privacy loss. (Note that these measurement designs all require a large amount of delay to address timing correlation.)

  • For attribution, we do think that an aggregated system is a good - even necessary - idea. However, we would defer any position on this until the Private Advertising Technology CG (and the upcoming working group) make progress on selecting a design for this use case.

• Ad selection based on browsing history. This is essentially a major component of FLEDGE or TURTLEDOVE, just in a new form, though it might also integrate aspects of Topics. We have not yet formed a final position on this style of targeting, especially since this is a long way from being ready for standardization.

From the perspective of these use cases, we would probably defer a position on this. PATCG is currently discussing attribution, and we are more likely to support the outcome of that process - and oppose any alternative. As noted, reach and frequency are better addressed by other efforts. Finally, we are not yet in a position to speak to the merits of the ad targeting use case.

However, even if we did support this from the perspective of these use cases, there are major shortcomings to this approach. This makes us concerned that the design might be inherently incapable of providing the sort of privacy that we wish to ensure for web users. That is, that they retain control over what knowledge of their actions on a site is shared with other sites.